Remote access to services over the Internet has provided consumers with access to theft desired services from virtually any location 24 hours a day and 365 days a year. Additionally, the service providers often outsource many of theft features to other remote third-party providers. In fact, the location of any particular service and the provider(s) of that service have now become transparent issues that are of little concern to end users. Users can also now access these remote services from mobile devices, such as phones, from even the remotest of geographical locations.
One problem with omnipresent access to services that may be provided from all over the globe is security. Of particular concern is the time lapse during which no activity is detected on the part of the user when accessing a service. Another problem associated with inactivity is that if the user is truly done accessing a service then unnecessary resources are being consumed by the service providers in keeping a user's session active.
In fact, it is a common security practice to use a setting called activity timeout to help secure systems against unauthorized tampering and to free up system resources by closing the users session if there is no activity for some configurable period of time. Use of timeout settings is critical for web-based solutions because many times the user does not “log out;” he/she just close his/her browser application. While most web-based solutions routinely set inactivity timeouts, this is usually accomplished using the “container timeout” in products such as Tomcat.
Many customer solutions built today are complete user solutions that include many component services existing in different containers, which may run on many computers from a variety of locations. For maximum usability, the end user should not be aware of the fragmented nature of the solution. Authentication can be performed via federation so the user continues to experience a true single sign on experience.
In a federated authentication system, each service component receives an authentication token, such as a Security Assertion Markup Language (SAML) token, and uses that token to build its own session. This means that if a solution has 4 service components there could be up to 5 sessions in 5 containers on 5 servers; one for the identity provider (the token builder) and one for each of the service components (the token consumer). However, each component service times out at a different rate across the multi-component system. Furthermore, a single service component can only know about its own activity and not the activity of other service components within the overall system. So, components services time out at different rates across a multi-component system. This means that one service component of a customer solution can time out while another service component is active with the customer, creating: system instability, poor integration, and customer solution failure. Synchronization of per-system activity timeouts across multi-component service solutions become problematic as more and more of these complex software and information services move to the web and to virtual environments (which as discussed above they are).